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Abstract 

This paper describes recent human-in-the-ioop 
research in the Airspace Operations Laboratory 
at the NASA Ames Research Center focusing on 
en route air traffic management with advanced 
trajectory planning tools and increased levels of 
human-automation cooperation. The decision 
support tools were exercised in a simulation of 
seven contiguous high-altitude sectors. 
Preliminary data suggests the controllers were 
able to manage higher amounts of traffic as 
compared to today, while maintaining 
acceptable levels of workload. 

1 Introduction 

The National Airspace System (NAS) is 
expected to face challenging increases in 
demand, as traffic levels are predicted to grow 
over the coming years [1], Additionally, a 
major limiting factor in how much the air traffic 
control system can handle is the controller’s 
workload and mental resources [2], [3]. Prior 
research has presented the potential benefits of 
data link, Automatic Dependent Surveillance- 
Broadcast (ADS-B), medium-term conflict 
probing, and trial-planning functions [4, 5, 6, 7]. 
This paper describes how all of these 
technologies have been integrated together into 
a prototype emulation of the Display System 
Replacement (DSR) platform, using the Multi- 
Aircraft Control System (MACS) [8]. 
Considering the application of a tool suite that 
includes automated functionalities and advanced 
decision support tools, the air traffic controllers 
are expected to experience a reduction in their 
workload, allowing them to handle increased 
levels of traffic. 


The results in this paper were gathered 
during a real-time human-in-the-loop simulation 
conducted in 2009 in the Airspace Operations 
Laboratory (AOL) at the NASA Ames Research 
Center [8, 9]. Shown in Figure 1, the simulation 
airspace included seven high-altitude sectors 
(FL290 and above) from the eastern part of the 
Kansas City Air Route Traffic Control Center 
(ZKC). Each of the seven sectors was staffed 
with one radar controller, four of whom were 
current Certified Professional Controllers 
(CPCs), and three were recently retired 
controllers. Data was collected over 16 runs, 
eight of which were “Traffic Load” scenarios, 
and eight of which were “Weather” scenarios. 
The traffic load scenarios were designed as 
problems of higher traffic levels, and the 
weather scenarios included dynamic weather 
cells with “tops” of 50,000ft MSL, which would 
require lateral re-routes to deviate around the 
weather. All scenarios lasted 75 minutes, and 
consisted of approximately 75% en route, level 
flights at cruise altitudes, and 25% transitioning 
aircraft related to local area airports. In general, 
the scenarios exhibited slightly heavier flows 
from the West-East/East- West, as compared to 
the North-South/South-North flows. 
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2 A Data Communications Environment 

The operational environment used in this 
simulation assumed 100% aircraft equipage, 
meaning all aircraft had ADS-B, data 
communication (Data Comm) for both Transfer 
Of Communication (TOC) and trajectory 
change messages, and a Flight Management 
System (FMS) with integrated Data Comm 
communication to allow for loadable trajectory 
clearances. 

Using Data Comm for the automated 
transfer of communication removed the need for 
controllers to verbally issue frequency change 
instructions to aircraft. The controllers still 
manually initiated and accepted handoffs, but 
did not have to verbally instruct each outgoing 
aircraft to change to the next frequency. 
Another assumption within the simulation was 
that aircraft would not do verbal check-ins, 
relieving the controllers from having to 
acknowledge the radio check-ins of each 
incoming aircraft. In the simulation, this was 
supported by the use of “monitor” TOC 
messages, rather than “contact” TOC messages, 
as shown in Figure 2. Participants from 
previous research in the AOL indicated this was 
the preferred mode of operation for full Data 
Comm equipage. 
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Fig. 2 View of Data Comm T ransfer of 
Communication (TOC) message from the ATC (top) 
and flight deck (bottom) perspective. 

The controller workstations also had 
trial-planning functions that allowed the 
controller to construct provisional trajectories 
and send them via Data Comm to the aircraft. 
Using primarily the trackball (keyboard 
commands were also available), the controller 
starts a trial-plan and can move, insert, and 
delete points along an aircraft’s trajectory. 
Points can be dragged with the trackball to any 


location, allowing for both named points and 
latitude/longitude points. With a single 
command, the controller can then uplink the 
trial-plan to the aircraft as a packaged route that 
can be directly loaded into its FMS, as 
illustrated in Figure 3. At the same time that the 
trajectory Data Comm message is sent, the 
ground system’s stored flight plan is amended. 
This updated flight plan is then used by the 
ground system for future computations. 



MOD RTE 

- ^ 

1 LEGS 1/1 

8175 NM 


[— N3 94 4 2 WO 90332 

246/37000 

70 720 NM 


[— N39519W090086 

246/37000 

95 V175 NM 


r — vhp 

246/37000 

91 V161 NM 


[ — CMH 

150/800 

H 


f— <ERASE 

RTE DATA> 




SL 

AID DATA STATUS 

SWA6 15/ 11617 RTE ( VHP ) WIL 


Fig. 3 A trial-plan prepared by the controller (top), 
then sent to the flight deck as an FMS-loadable 
message (middle), followed with the response 
message received (bottom). 


The trial-planning function can also be 
used for altitude changes, either as a separate 
trial-plan or combined with a lateral 
modification. Data Comm-enabled trial-plans 
have the potential benefit of reducing a 
controller’s workload associated with radar 
vectoring; turn-outs and turn-backs can be 
replaced with a complete “hand-drawn” 
trajectory designed by the controller. Flight 
crews accept the Data Comm clearances 
electronically as well, which further reduces 
frequency congestion by replacing the clearance 
read-backs. 


2 






AN INTEGRATED TO 0 L SU ITE FO R E N RO UTE RAD AR 

CONTROLLERS IN NEXTGEN 


3 Human-Automation Cooperation 

Conflict detection automation was integrated 
directly into the DSR screen, complementing 
the controller’s scan and minimizing disruptions 
to their workflow. The conflict detection probe 
within MACS uses a deterministic search for 
conflicts along the trajectories of the ground 
system’s stored flight plans. In case aircraft are 
out of conformance with their trajectory, 
ADS-B state information from the aircraft is 
used to create a five-minute “dead reckoning” 
trajectory. Detected conflicts are presented to 
the controller both in the top right of the Flight 
Data Block (FDB) as a number (minutes until 
predicted loss of separation), and in a conflict 
list view. 

The conflict detection probe also checks 
trial-planning trajectories. If the system detects 
a conflict between two aircraft, the controller 
can start a trial-plan and drag or move a point 
on the route of one of the conflict aircraft, and 
in real-time the conflict detection probe 
continuously checks the provisional trial-plan 
for conflicts with other aircraft. Potential 
conflicts are clearly indicated on the screen, and 
it becomes a visual search task for the controller 
to move the trial-plan until it appears conflict- 
free, as illustrated in Figure 4. This 
functionality was implemented in a manner that 


provides highly responsive feedback to the 
controller, making it very easy to use and still 
very useful in high workload and/or time- 
critical situations. 

An on-demand automatic conflict 
resolution algorithm was also included, which 
provided efficient trajectory changes to resolve 
medium-term conflicts [10]. If the ground 
system detects a conflict between two aircraft, 
the controller can request a conflict resolution 
from the automation by clicking on the conflict 
indications in the flight data block or the 
conflict list view. Wit hin a few milliseconds, a 
conflict-free resolution is presented to the 
controller as a trial-plan. Presenting the 
resolution in this way allows the controller to 
“tweak” the resolution if necessary, and then 
send it to the aircraft in the same way manual 
trial-plans are uplinked. 

Additionally, a simple deterministic 
weather probe was incorporated, alerting the 
controllers to predicted weather penetrations. 
The weather probe information was presented to 
the controllers in the form a blue number 
(minutes until predicted weather penetration) in 
the bottom right of the FDB, as shown later in 
Figures 6 and 7. While trial-planning to avoid 
the weather, the controllers would move the 
trial-plan until the weather probe’s number 
would disappear. 



Fig. 4 The trial-planning function and conflict detection automation (left). A short visual search discovers that 
dragging the trial-plan to the south creates a conflict-free trajectory (right). 
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Fig. 5 Average aircraft count across all test sectors (left), and average workload-rating across all test sectors (right). 


4 Traffic Scenarios and Workload 

The controllers’ experience of the two different 
traffic scenarios can be characterized in terms of 
aircraft count and real-time workload ratings. 
The aircraft count will serve to describe the 
general traffic density of the scenarios, and the 
workload ratings will give the reader an 
indication of how “busy” the controllers felt 
during the scenarios. 

The average aircraft count recorded 
during the simulation is reported in Figure 5. 
The traffic load scenarios were slightly higher 
than the weather scenarios, being designed for 
traffic levels to peak near 22 aircraft at a given 
time inside the test sectors. The weather 
scenarios reached as high as 16 aircraft, but 
despite the lower aircraft count, had the 
additionally constraint of dynamic weather cells 
that needed to be avoided. 

During each simulation run, the 
controllers were prompted every three minutes 
to report their current workload while 
controlling traffic. Using Workload Assessment 
Keypads (WAKs), they rated their workload on 
a 1 to 6 scale where ratings of 1 and 2 were 
considered to be low workload, ratings of 3 and 
4 were considered to be medium workload, and 
ratings of 5 and 6 were considered to be high 
workload. The right side of Figure 5 indicates 
that the workload for the weather scenario was 
comparable to the workload of the traffic load 
scenario, suggesting that although the aircraft 
counts were different between the two 
scenarios, there were other characteristics that 
made them have a similar “feel,” suggesting that 


the scenarios were equally complex. These two 
sets of data serve to provide the reader with a 
general picture of the working environment 
experienced by the controllers, which can be 
seen as the input parameters into the controllers’ 
use of the tools described in this paper. 

5 Manual Trajectory Planning Usage Data 

The trajectory planning tools at the sector 
positions were a continuation of radar controller 
tools that had been developed and tested in 
previous experiments in the AOL [8]. The 
primary goal behind building these tools is to 
provide the controller with highly-responsive 
trajectory manipulation tools that are integrated 
with Data Comm and represent fundamental 
building blocks for operations within the Next 
Generation Air Transportation System 
(NextGen) [11] operations. The controllers 
heavily used the trajectory planning tools for 
managing traffic and resolving conflicts, as 
discussed in the following sections. 

5.1 Initiation Method 

The radar controllers could start a trial-plan in 
any of a number of ways, either by clicking on 
certain fields within the FDB, or with certain 
DSR keyboard commands. Graphically from 
the FDB, the controller could use the altitude 
fly-out menu (displayed by clicking on the FDB 
altitude), or click on a trial-planning “portal”, 
which would also display the direct-to route fly- 
out menu. Figures 6 and 7 show the trajectory 
planning access points within the prototyped 
FDB. Available DSR keyboard commands 
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Fig. 6 Altitude trial-planning from the altitude fly-out 
menu 



Fig. 7 A trial-plan can be started from the FDB trial- 
planning portal (arrow symbol to the right of the 
callsign). Also displayed is the direct-to fly-out menu, 
another method for making modifications to the 
lateral routing. 

were “TA” for altitude trial-planning, “TR” for 
route (lateral path) trial-planning, and “TT” for 
toggling on and off (i.e., starting and cancelling) 
trial-plans. 

As mentioned before, the controllers 
used the manual trajectory planning tools often 
throughout the simulation. In total, 3,539 trial- 
plans were started during the simulation. 
However, trial-plans can also be canceled at any 
time, so this number is distinct from how many 
trial-plans were actually sent to aircraft. Data 
regarding trial-plan uplinks will be discussed in 
section 7. 

Of all the trial-plans initiated, Figure 8 
indicates that the controllers most frequently 
started altitude trial-plans (M=20.8 per run). 
Clicking the portal (represented in Figure 8 as 
“trial plan portal”) and using the TR keyboard 
command (represented in Figure 8 as “trial plan 
route”), were nearly equally used (M=8.2 and 


10.7 per run, respectively). It appears that the 
controllers were least likely to use the TT 
keyboard command (represented in Figure 8 as 
“trial plan toggle”), on average using it only 2.6 
times per run. 

The data shows that the controllers had a 
preference for trying altitude maneuvers in the 
traffic load scenarios. The increase in use of 
altitude maneuvers in the traffic load scenarios 
as compared to the weather scenarios suggests 
that, when given the option, the controllers 
preferred to use altitude for resolving traffic 
conflicts. Section 5.3 will further examine the 
use of altitude trial-plans in the presence of 
conflicts. 


Average # of Trial-Plans Initiated, by Method 



Fig. 8 Average number of trial-plans manually 
initiated by the controllers. 


During the weather scenarios, due to the 
high tops of the weather cells, solutions to 
predicted weather penetrations were always 
lateral maneuvers. Consequently, when altitude 
trial-plans were used in the weather scenarios, it 
was in response to some traffic conflicts or for 
transitioning aircraft related to local airports. 


5.2 Lateral Maneuvers 

When controllers designed trial-plans that 
modified the lateral path of aircraft, data was 
analyzed to gain insight into what type of 
changes were made in those cases. Between 
inserting auxiliary waypoints and removing 
existing waypoints, the controllers more often 
inserted an auxiliary waypoint. Illustrated in 
Figure 9, controllers added auxiliary waypoints 
more than ten times more often than they 
removed existing waypoints. 
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Average # of Lateral Maneuvers, by Type 



Traffic Load Weather 


Fig. 9 Average number and type of recorded lateral 
manuevers associated with the manual trial-plans 
from the controllers. 

The data (shown as average count per 
run), exhibits this pattern in both traffic 
scenarios, and is expected as such, because the 
controllers worked within a relatively short time 
horizon (e.g., 15 minutes), within which it was 
less likely that a shortcut or “direct-to” to a 
downstream fix would provide a sufficient 
heading change for an aircraft to avoid a loss of 
separation (LOS), let alone avoid a weather cell. 


5.3 The Presence of Conflicts 

Trajectory planning data was analyzed to 
investigate how the controllers used the manual 
trial-planning tools with special regard to 
conflicts. During the simulation, aircraft could 
potentially come into conflict with other 
aircraft, weather cells, or both. Figure 10 shows 
how often controllers used the trajectory 
manipulation tools in the presence of a conflict. 
From the data in Figure 10, we see that the 
majority of trial-plans were initiated when there 
was no conflict detected for the aircraft. This is 
indicative of two things: transitioning aircraft 
related to local area airports, and the controllers’ 
natural tendency to organize the traffic with the 
application of “positive control.” 

For aircraft landing at local airports, it 
was co mm on for the controllers to use the trial- 
planning functions to send a descent clearance 
to the aircraft, in order to start their descent 
early. An example of this, often seen in the 
simulation, was a cruise-altitude descent to 


FL290, built with the trial-plan and sent to the 
aircraft via Data Comm. 

Positive control is a more conservative 
strategy of keeping aircraft organized in a way 
that minimizes the potential of traffic conflicts. 
This approach, which in some way can be 
thought of as “staying ahead of the conflict 
probe,” often involves changing the altitudes 
and/or routings of aircraft at opportune times, so 
as to distribute the traffic vertically as well as 
laterally in the sector. 

These two possible explanations are 
supported by the data in Figure 11, which 
confirms that with no conflict present, more 
than two-thirds of the trial-plans initiated were 
for altitude changes. Interestingly, the weather 
scenarios showed a slight increase in the relative 
amount of route trial-plans, again likely due to 
the high tops of the simulated weather. 


% of Start Trial Plan events, by Conflict Status 



I w / no conflict 
i w/ traffic conflict 
i w/ weather conflict 
l w/ both conflicts 


Traffic Load 


Weather 


Fig. 10 Proportion of trial-plans started by the 
controller that were or were not in conflict at time of 
trial-plan initiation. 


% of Trial-Plans Initiated, by Method, for No Conflicts 



w/ no conflict w/ no conflict 

Traffic Load Weather 


Fig. 11 Proportion of trial-plans, either altitude or 
route, initiated in non-conflict situations. 
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A similar altitude-preference was found 
for the trial-plans that were in response to a 
traffic conflict. In those cases, 89% of the time 
the controller’s initial response was to try an 
altitude maneuver (see Figure 12). This is 
supported by controllers’ comments that for 
traffic conflicts, altitude changes more quickly 
move conflicting aircraft away from each other. 

As expected, when a weather conflict 
was detected for an aircraft, lateral trial-plans 
were most co mm on. The relatively few altitude 
trial-plans that were initiated in response to a 
weather conflict were due to aircraft that were 
transitioning to and from weather-impacted 
airports. Because high altitude airspace was the 
focus of this simulation, (the test sectors were 
FL290 and above), and weather contingencies 
such as diverting to alternate airports were 
outside of the scope of the simulation, the 
controllers issued the appropriate altitude 
changes and handed the aircraft off to the low 
altitude airspace. Operations in the low altitude 
airspace were not properly simulated, and not 
intended to be included in these data analyses. 


% of Trial-Plans Initiated, by Method, for Conflicts 



Traffic Load 


Weather 


Fig. 12 Proportion of trial-plans, either altitude or 
route, initiated in response to traffic and weather 
conflicts. 


6 Automation-Assisted Trajectory Planning 
Usage Data 

Another trajectory planning tool available to the 
controllers was the Advanced Airspace 
Concept’s (AAC) Auto-Resolver [10]. With 
this Decision Support Tool (DST), the 
controllers can ask the Auto-Resolver’s 
automation, in the presence of a detected traffic 


conflict, to suggest a provisional trajectory that 
resolves the conflict. During the simulation, 
this function was made accessible to the 
controllers in four ways: with a Trackball-Enter 
on the conflict probe number in the upper-right 
of the FDB, with a Trackball-Enter on the trial- 
planning portal, with a Trackball-Enter on the 
altitude line of the FDB, and with a Trackball- 
Enter on the conflict list entry for the aircraft 
pair in conflict (see Figure 13). 


♦FLG394-* 5 
320C 

3851 417 23 


TIME H- SEP V-SEP BXS 



♦NWA283-» 5 
320C 

4024 420 37 


Fig. 13 Two aircraft in conflict, FLG394 (top, 
southwest bound), and NWA283 (bottom, northwest 
bound), showing conflict probe numbers in the upper 
right of their FDB. The conflict list is also displayed. 


More than just variety, the different 
access points to the Auto-Resolver help the 
operator communicate resolution preferences to 
the automation. Consider Figure 13: if the 
controller clicks in the conflict list, this implies 
they have no preference over which aircraft 
should be moved, and also no preference for 
which type of maneuver (lateral or vertical) is 
used. If the controller clicks the conflict probe 
number in the FDB of the NWA283 flight, this 
implies they prefer that the NWA283 receive 
the resolution, but still have no preference for 
which type of maneuver. However, if they click 
the trial-planning portal for the FLG394, the 
automation would understand that the controller 
prefers that the FLG394 receive the resolution, 
and that they prefer the resolution to be a lateral 
maneuver. If they instead click on the altitude 
line of the FDB for FLG394, this would imply a 
preference for a vertical resolution for that 
aircraft. 
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6.1 Request Method 

Figure 14 shows another clear preference by the 
controllers. The data (shown as average count 
per run) indicates they most often requested the 
automated resolutions from the FDB, as 
opposed to the conflict list. More specifically, 
out of the nearly 600 requests to the automation 
for conflict resolutions, 94% of those requests 
were made from either the trial-planning portal 
or the conflict probe number in the upper right 
of the FDB. Note that data for these two access 
points are combined together. Unfortunately, at 
time of writing, they were unable to be analyzed 
separately. 



Fig. 14 Average number of requests from the 
controllers for automation resolutions. Data shown is 
organized by the different Auto-Resolver access 
points. 


6.2 Success/Failure Rates 

Each request of the Auto-Resolver to provide a 
conflict resolution trajectory can either succeed 
or fail. Data was also analyzed to help quantify 
how the Auto-Resolver functioned. 

Figure 15 illustrates that the Auto- 
Resolver performed as a very effective DST, 
reliably providing the controller with conflict 
resolution trajectories. During the simulation 
there were only 22 recorded failures of the 
automation to generate a resolution, equating to 
a 3.8% failure rate. The failures to provide a 
resolution can be attributed to one of two 
causes. Primarily, there were known issues with 
the integration of the Auto-Resolver logic into 
the MACS software. These implementation 
short-comings have since been addressed in 


more recent versions of the MACS software, 
and also addressed with an updated version of 
the Auto-Resolver [10]. 

The second cause of these resolution 
failures was when the controllers requested the 
resolution under very short look-ahead times 
(e.g., less than two minutes until predicted 
LOS). With longer look-ahead times, the Auto- 
Resolver used during this simulation worked 
very well, but when presented with very short 
look-ahead times, resolutions to a predicted 
LOS were not always possible. The maneuver 
rate limits of the aircraft, in addition to the 
execution delays of operators, can cost valuable 
seconds that would be needed for such 
imminent conflicts. In these cases, a more 
direct, or tactical resolution would need to be 
provided directly to the flight crew (not through 
the FMS), as done with TSAFE [12], which was 
not used during this simulation. 


Automation Success/Failure Rate 

400 
350 
300 
250 
200 
150 
100 
50 
0 

Traffic Load Weather 


Fig. 15 Total number of times the Auto-Resolver 
automation succeeded and failed to provide a 
resolution for a traffic conflict. 


7 Usage of Data Comm for Sending T rial- 
plans 

An initial look at the number of trial-plans 
uplinked to aircraft seems to confirm the 
controllers’ frequent use of the trajectory 
planning tools. Figure 16 (shown as average 
count per run) indicates that slightly more than 
38 and 45 trial-plans were uplinked in the traffic 
load and weather scenarios, respectively. Given 
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that each run lasted 75 minutes, in the traffic 
load scenarios, this equates to approximately 3 1 
trial-plan uplinks per hour, or roughly one 
uplink every two minutes. 

The increase in the number of trial-plans 
uplinked in the weather scenarios is expected, 
and is likely due to the nature of the weather’s 
movement. The weather forecast used to 
generate the weather probe numbers was 
intentionally not perfect, and as the weather 
moved over the course of the scenario, it was 
possible that an aircraft that was previously re- 
routed to avoid weather would need to be 
moved again. This is not unrealistic, and did 
contribute to more trial-plans being sent to 
aircraft during a weather scenario, at a rate of 
approximately 36 uplinks per hour. 


Average # of Trial Plans Uplinked 

50 
45 
40 
35 
30 
25 
20 
15 
10 
5 
0 

Traffic Load Weather 

Fig. 16 Average number of trial-plans sent to aircraft, 
categorized by traffic scenario. 

8 Subjective Feedback Data 

In a post-simulation questionnaire, the 
controllers were asked to rate the tools in terms 
of how helpful they were (usefulness) and how 
easy they were to use (usability), on a scale 
from one through six, with one signifying not at 
all useful/usable, and six signifying very 
useful/usable. The average usefulness and 
usability ratings from the seven controllers can 
be seen in Figure 17. The data indicates that the 
automatic TOC was the highest rated function 
(M=5.9 for both usefulness and usability). This 
is not surprising, because radio check-ins from 
incoming aircraft and frequency changes for 
outgoing aircraft today constitute a large 


amount of workload for controllers. Data 
Comm operations (and the tools that support 
them) where that task is no longer needed, 
would understandably be well-received by 
controllers. Even with the high ratings, the 
controllers did report a few minor problems 
with the Data Comm TOC, commenting that in 
a few cases they would have liked to initiate 
hand-offs while an aircraft still had open Data 
Comm messages, rather than waiting for the 
pilot response message. 

The conflict probe was the second- 
highest rated tool (M=5.4 usefulness, M=5.5 
usability), and similar to the automatic TOC 
rating, is a sign of how much of a controller’s 
current-day workload is related to detecting 
traffic conflicts themselves. These ratings 
suggest that the conflict probe, as implemented 
in the MACS software, is very reliable, and 
therefore a very helpful tool. 

The manual trajectory-planning tools 
were also highly rated, with all components 
receiving a rating of 5 or higher for both 
usefulness and usability. Most of the controller 
comments in this area spoke to their preference 
for altitude solutions. For example, the 
controllers mentioned that they would have 
liked an easier way to manually identify a 
conflict-free altitude with the trial-planning tool. 
Whereas for lateral solutions where the trial- 
planning task is a straight-forward “visual 
search while dragging” process, for vertical 
solutions, the trial-planning task involves trying 
different Flight Levels (FL) one-by-one. Trying 
each altitude involves two or more clicks of the 
trackball buttons, which can add up to a 
relatively long time if the controller needs to 
check several options before finding a clear 
altitude. 

The automation-assisted trajectory- 
planning tools were rated as both useful and 
usable, with the lateral resolutions from the 
automation receiving higher ratings than the 
vertical resolutions (M=4.8 usefulness, M=5 
usability, and M=4.3 usefulness, M=4.8 
usability, respectively). However, comments 
from the controllers indicated that a few minor 
improvements were still needed. 

The controllers commented that they 
would have liked the altitude resolutions from 



9 


J. MERCER, T. PR EVOT, C. BRASIL, M. MAIN INI, M. KUPFER, N. SMITH 


Usefulness & Usability Ratings for Controller Tools/Functions 

AutomaticTransfer of Communication 
Conflict Probing 
TA (Altitude Trial Planning) 

TT (Trial Planning) 

Graphical Trial Planning 
TR (Route Trial Planning) 

Auto-Generation of Trajectory for Conflict Avoidance 
Auto-Generation of Altitude for Conflict Avoidance 
Weather Penetration Probing 

0 1 2 3 4 5 6 

Not at all Useful/Usable (1) - Very Useful/Usable (6) 

Fig. 17 Usefulness and usability ratings from the radar controllers for the provided toolset. 


I Usefulness 
Usabilty 


the Auto-Resolver to account for standard 
direction of flight rules, and that the altitude 
resolutions should also avoid issuing higher 
altitudes to aircraft that were nearing their 
destination and would need to descend anyway. 
In general though, the controllers’ comments 
were very positive towards the trial-plans 
generated by the automation. Some of the 
controllers commented that they “used the auto 
resolution more than [they] thought they 
would,” and that they were thinking of ways to 
fine-tune the Auto-Resolver’s logic to align 
with their control preferences. This type of 
thinking is evidenced by one controller’s 
comment to have the Auto-Resolver pick lateral 
maneuvers (small, easy turns) for conflicts 
8-12 minutes away, and altitude maneuvers for 
conflicts closer in. 

9 Future Work 

The simulation brought to light some areas for 
improvement and further research. The altitude 
trial planning will be improved by re-activating 
a functionality that was suggested and tested by 
McNally, Erzberger, Bach, and Chan (1999) 
[13]. This functionality probes all nearby 
altitudes and indicates their conflict status inside 
the altitude pop-up menu. This way a controller 
can see which altitudes are usable without 
starting a trial plan first. 

In addition, the trajectory manipulation 
tools did not include control over the speed 


domain, something the controllers asked for. 
Further work needs to be done on how to best 
implement speed changes within the current 
trial-planning paradigm. Future analyses of tool 
usage data can also be expanded to include 
details on what type of trial-plans were uplinked 
(lateral, vertical, etc.) and the timing of the 
various steps involved in the trial-planning 
process. The authors also plan further analyses 
to compare what type of maneuver was 
preferred during a request from the Auto- 
Resolver, versus what type of maneuver was 
actually provided by the Auto-Resolver. 

10 Concluding Remarks 

This paper describes results gathered during a 
human-in-the-loop simulation that provided 
active CPC radar controllers with prototype 
tools supporting NextGen-type operations. 

Although it was not the focus of the 
simulation, higher levels of traffic were worked 
with acceptable levels of controller workload. 
Not only were the observed traffic levels higher 
than today’s traffic, the sectors were staffed 
with only the radar controller; not with any 
additional radar associate controllers. 
Simulating a two-controller sector team was 
outside the scope of this simulation, so this 
result in no way is meant to address staffing. 
Instead, the results speak to a potentially 
effective cooperation between human operators 
and the system automation. Specifically, these 
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results suggest that this suite of tools could help 
off-load routine tasks from the controllers and 
provide assistance with tasks that can be 
difficult for the controller. This could then 
allow the controllers to focus their resources on 
other tasks, such as providing higher levels of 
service to the airspace users, attending to high- 
complexity areas, or even manage more aircraft. 
Similarly, the notion of a controller discussing 
how the Auto-Resolver logic could be adapted 
to their individual control strategies and 
preferences indicates an initial level of trust in 
the automation was achieved during the 
operations simulated in this study. Overall, the 
results of this simulation have demonstrated that 
critical building blocks of NextGen operations, 
such as automated conflict detection, automated 
conflict resolution, trial-planning, and Data 
Comm, can be effectively integrated into the 
radar controller workstation. 
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